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DOCUMENT MANAGING APPARATUS FOR MANAGING 
TRANSACTION SLIP DATA IN ELECTRONIC COMMERCE 

Background of the Invention 
5 Field of the Invention 

The present invention relates to a document 
managing apparatus for managing transaction slip 
data in electronic commerce. 

10 Description of the Related Art 

As the Internet has become common, 
transactions are being aggressively carried out on 
the network. When transactions are carried out on 
the network, electronic data such as transaction 

15 slip data should be managed and used. In particular, 
since many transaction parties are connected to the 
network, the amount of transaction slip data 
becomes huge. In addition, when companies as 
transaction parties use different transaction slip 

20 data formats, the data formats should be converted. 

The transactions carried out on the network are 
referred to as electronic commerce. In the 
electronic commerce, a technology called EDI 
(Electronic Data Interchange) is becoming important. 

25 As a standard technology for solving 
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compatibility and convenience of electronic data in 
the open environment, it is expected to use XML 
data in the electronic commerce. When a large 
amount of XML data is stored, it is necessary to 
5 select an adequate data structure for an electronic 
data exchanging process (such as data reception, 
data transmission, data manipulation (for example, 
format conversion, data compression, data 
decompression, and data division) , and data 

10 shuffling) and to designate the selected data 
structure as a search condition. 

As a conventional technique for storing XML 
data to a database, an XML document is stored as a 
file to the database. 

15 In the electronic data exchanging process for 

inter-company electronic commerce, transaction 
slips are generally processed corresponding to a 
particular information field such as a slip 
category, each slip acceptor, or each slip issuer. 

20 Thus, the searching efficiency of a particular 
field of transaction slip data should be improved. 

Fig. 1 shows a schematic diagram for 
explaining a problem of the conventional electronic 
commerce . 

2 5 In an inter-company electronic commerce system 
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using a database device that directly stores an XML 
document as a file, transaction slip data is stored 
in its data structure. Thus, when the amount of 
transaction slip data becomes huge as in a large 
5 inter-company electronic commerce system, 

transaction slip data cannot be searched in a 
desired time period of the electronic data 
exchanging process. 

In the electronic data exchanging process of 

10 the inter-company electronic commerce, transaction 
slip data for a particular order acceptor may be 
extracted from seder data of many order issuers and 
converted into the format of the particular order 
acceptor. For example, transaction slip data may be 

15 searched with a search key of particular data that 
identifies an order acceptor described in 
transaction slip data. In other words, transaction 
slip data is generally searched for a particular 
element thereof. 

20 However, conventionally, all transaction slip 

data stored in an order issuer server is searched 
for transaction slip data for companies P, Q, and R 
as order issuers. The extracted transaction slip 
data is transmitted to the order acceptor server. 

25 In the order acceptor server, for example, order 
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slip data for the company P as a search object is 
extracted from all the received transaction slip 
data. The extracted data is transferred to the 
company P . 

5 Transaction slip data used in the inter- 

company electronic commerce is generally composed 
of a header portion and a record portion. The 
header portion contains parameters necessary for an 
electronic data exchanging process. The record 

10 portion contains detail data as the content of an 
order. In the electronic data exchanging process 
performed in an order issuer server and an order 
acceptor server, it is necessary to reference only 
the parameters for the electronic data exchanging 

15 process. 

Fig. 2 is a schematic diagram showing an 
example of transaction slip data described as an 
XML document. 

A data storing portion of an XML document is 

20 referred to as XML instance. The XML instance is a 
tagged text as shown in Fig. 1. 

When an XML document containing such an XML 
instance is searched for data of a particular tag 
as a search condition, the efficiency of the 

25 searching process depends on the amount of data 
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surrounded by tags of the XML document. For example, 
in the electronic data exchanging process, when an 
XML document containing an XML instance is searched 
for data of "an order acceptor code", if all the 
5 XML file is searched, data surrounded by <record> 
and </record> tags is also searched. Occasionally, 
a portion surrounded by the <record> and </record> 
tags may contain a large amount of detail data. 

Thus, in the inter-company electronic commerce 
10 using an XML document as transaction slip data, it 
is necessary to speed up the searching process 
using a search key of particular element data such 
as parameters necessary for the electronic data 
exchanging process. 

15 

Summary of the Invention 

An object of the present invention is to 
provide a document management system that allows 
20 transaction slip data to be effectively managed in 
electronic commerce. 

The present invention is a managing apparatus 
for managing a transaction slip data document used 
in electronic commerce with a database device, 
25 comprising a data extracting means for extracting 
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data as a search item of the transaction slip data 
document therefrom, a storing means for storing the 
data extracted by the data extracting means as 
management data in correlation with the transaction 
5 slip data, a transaction slip data extracting means 
for searching the management data so as to extract 
correlated transaction slip data, and a 
transmitting means for transmitting the transaction 
slip data extracted by the transaction slip data 

10 extracting means. 

According to the present invention, 
transaction slip data that is transmitted from many 
order issuers to order acceptors can be searched 
for individual order acceptors at high speed. In 

15 addition, in the process for transaction slip data, 
a trouble due to an insufficient process 
performance of the managing apparatus can be 
prevented. 

These and other objects, features and 
20 advantages of the present invention will become 
more apparent in light of the following detailed 
description of a best mode embodiment thereof, as 
illustrated in the accompanying drawings. 

25 Brief Description of Drawings 
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Fig. 1 is a schematic diagram for explaining a 
problem of conventional electronic commerce; 

Fig. 2 is a schematic diagram showing an 
example of transaction slip data described as an 
5 XML document; 

Fig. 3 is a block diagram showing the basic 
structure of an embodiment of the present 
invention; 

Fig. 4 is a flow chart showing a transaction 
10 slip data storing process of a database managing 
module; 

Fig. 5 is a flow chart showing a content data 
extracting process of the database managing module; 

Fig. 6 is a schematic diagram showing 
15 management data and content data stored in a 
database device; 

Fig. 7 is a block diagram showing the 
structure of the system according to the embodiment 
of the present invention; 
20 Fig. 8 is a schematic diagram showing the 

structure of the system according to the embodiment 
of the present invention in the case that there are 
a plurality of order issuers, a plurality of order 
acceptor server devices, and a plurality of order 
25 acceptors; 



Fig. 9 is a schematic diagram for explaining a 
transaction slip data format converting process (No. 
1) ; 

Fig. 10 is a schematic diagram for explaining 
5 the transaction slip data format converting process 
(No. 2); 

Fig. 11 is a flow chart for explaining the 
transaction slip data format converting process (No. 
3) ; 

10 Fig. 12 is a schematic diagram for explaining 

a content data transferring process (No. 1) ; 

Fig. 13 is a flow chart for explaining the 
content data transferring process (No. 2); 

Fig. 14 is a block diagram showing the 
15 structure of the system in the case that each 
section of a company R has an order acceptor 
browser and settles transaction slip data (No. 1); 

Fig. 15 is a schematic diagram for explaining 
a process of the system shown in Fig. 14 (No. 2) ; 
2 0 and 

Fig. 16 is a block diagram showing an example 
of a hardware environment necessary for 
accomplishing a function of an order issuer server 
device or an order acceptor server device with a 
25 program. 
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Description of Preferred Embodiment 

When an electronic data exchanging process is 
performed in inter-company electronic commerce, 
5 transaction slip data is searched for particular 
element data as a search object. Thus, when 
transaction slip data is stored, element data as a 
search object is pre-stored to a management data 
area. As a result, when reguired transaction slip 

10 data is extracted in the electronic data exchanging 
process, the searching process is performed for 
only data stored in the management data area rather 
than all the transaction slip data. Thus, the 
searching process can be performed at high speed. 

15 Fig. 3 is a block diagram showing the basic 

structure of the embodiment of the present 
invention . 

The embodiment of the present invention 
comprises a database device 3 and a data managing 

20 module 2. The database device 3 contains table 
elements of XML document names and XML document 
data. The data managing module 2 executes a data 
storing process and a data extracting process for 
the database device 3. 

25 According to the embodiment of the present 
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invention, XML documents stored in the database 
device 3 can be categorized as two types. The first 
type is content data (XML document) used in the 
inter-company electronic commerce. The second type 
5 is management data (XML document) of which 
information (for example, order issuer information, 
order acceptor information, and transaction slip 
data type) that is frequently referenced from the 
content data in the electronic data exchanging 

10 process of the inter-company electronic commerce. 

Hereinafter, the first type and the second type are 
referred to as content data 5 and management data 4, 
respectively. 

The data managing module 2 has an API 

15 (Application Program Interface) used for the 

storing process. With the API for the storing 
process, transaction slip data 1 is input and 
stored. In addition, the data managing module 2 has 
another API used for the extracting process. With 

20 the API for the extracting process, a search 
condition 6 as a data element of transaction slip 
data 7 is input and transaction slip data 7 that 
matches the search condition 6 is output. 

As an initial setting of the data managing 

25 module 2, an XML document structure including a 
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group of data elements frequently referenced in the 
electronic data exchanging process should be pre- 
registered. The registered information is stored as 
management data document structure information 8 
5 and 9 to the data managing module 2. A data element 
designated as a search condition by the input API 
for the extracting process should be contained in 
the group of data elements registered as the 
management data document structure. 
10 Fig. 4 is a flow chart showing a transaction 

slip data storing process of the database managing 
module . 

At step S10, content data is read. At step Sll, 
the document structure of the content data is 

15 analyzed. Corresponding to the analyzed result, 
management data and the document structure thereof 
are extracted. At step S12, it is determined 
whether or not the document structure has been 
successfully analyzed. When the determined result 

20 at step S12 is No (namely, the document structure 
has not been successfully analyzed) , the flow 
advances to step S13. At step S13, an error message 
or the like that represents an error of the 
analyzing process is presented to the user and then 

25 the process is completed. When the determined 
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result at step S12 is Yes (namely, the document 
structure has been successfully analyzed) , the flow 
advances to step S14 . At step S14, the management 
data is output as an intermediate file (temporary 
5 file) . At step S15, a document identifier for 
identifying the content data that has been read at 
step S10 is obtained. Thereafter, the flow advances 
to step S16, At step S16, the management data and 
the content data are stored as a file "document 

10 identifier . ctl" and a file "document 

identifier.doc", respectively, to the database 
device 3. At step S17, it is determined whether or 
not the management data and the content data have 
been successfully stored to the database device 3. 

15 When the determined result at step S17 is No 
(namely, the management data and the content data 
have not been successfully stored to the database 
device 3) , an error message or the like is 
presented to the user so as to prompt him or her 

20 for a retry. When the determined result at step S17 
is Yes (namely, the management data and the content 
data have been successfully stored to the database 
device 3) , the process is completed. 

Fig. 5 is a flow chart showing a transaction 

25 slip data extracting process of the database 
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managing module. 

In the extracting process, at step S20, a 
search object data element and a search condition 
are read from the input search condition. A 
5 management data document name that matches the 
search condition is obtained from the management 
data 4 stored in the database device (at step S21) . 
At step S22, it is determined whether or not a 
management data document name has been successfully 

10 obtained. When the determined result at step S22 is 
No (namely, a management data document name has not 
been successfully obtained) , an error message or 
the like is presented to the user and the process 
is completed. On the other hand, when the 

15 determined result at step S22 is Yes (namely, a 
management data document name has been successfully 
obtained), the flow advances to step S23. At step 
S23, a content data document name as a search 
object is determined with the obtained management 

20 data document name and then the content data is 
extracted therefrom. In other words, the obtained 
management data document name has been assigned a 
document identifier in the storing process. In 
addition, since a unigue document identifier is 

25 assigned to each content data in each database 
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device, the content data 5 having assigned an 
obtained document identifier as a document name is 
content data 5 that matches the input search 
condition, the content data 5 having assigned the 
5 obtained document identifier is extracted from the 
database device 3. At step S24, it is determined 
whether or not content data has been successfully 
extracted. When the determined result at step S2 4 
is No (namely, content data has not been 

10 successfully extracted) , an error process is 
performed. In contrast, when the determined result 
at step S24 is Yes (namely, content data has been 
successfully extracted) , the flow advances to step 
S25. At step S25, the extracted content data is 

15 output and then the process is completed. 

Fig. 6 is a schematic diagram showing 
management data and content data stored in a 
database device. 

As shown in Figs. 4 and 5, when transaction 

20 slip data is stored to a database device, if the 
transaction slip data is divided into management 
data 4 and content data 5 and separately stored to 
the database device, the database device can be 
searched for only the management data 4 that 

25 matches a search condition as shown in Fig. 6. 
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In other words, it is not necessary to search 
all transaction slip data. Thus, the searching 
process can be performed at high speed. Even if a 
large amount of transaction slip data is stored in 
5 the data managing module 2 of an order issuer 
server or an order acceptor server, transaction 
slip data necessary for the electronic data 
exchanging process can be effectively searched. 

Fig. 7 is a block diagram showing the 

10 structure of the system according to the embodiment 
of the present invention. 

The system shown in Fig. 7 comprises an order 
issuer browser 11, an order acceptor browser 12, an 
order issuer server device 14, a database device 17, 

15 an order acceptor server device 16, a database 
device 18, Internet 13, and a network 15. The 
database device 17 is connected to the order issuer 
server device 14. The database device 18 is 
connected to the order acceptor server device 16. 

20 The Internet 13 is a network that connects the 
order issuer browser 11 and the order issuer server 
device 14 and that connects the order acceptor 
browser 12 and the order acceptor server device 16. 
The network 15 connects the order issuer server 

25 device 14 and the order acceptor server device 16. 
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The order issuer server device 14 comprises a 
WWW server 14a, a data managing module 14b, a 
conversion controlling module 14c, and a transfer 
controlling module 14d. The order acceptor server 
5 device 16 comprises a WWW server 16a, a data 
managing module 16b, a conversion controlling 
module 16c, and a transfer controlling module 16d 
that are the same as those of the order acceptor 
server device. 

10 Next, an order issuing process and an order 

receiving process of the system shown in Fig. 7 
will be described. In the order issuing process, an 
order is issued and transmitted by the order issuer 
browser 11. in the order receiving process, an 

15 order is received and accepted by the order 
acceptor browser 12 . 

The WWW server 14a of the order issuer server 
device 14 receives an XML document of order slip 
data from the order issuer browser 11. The data 

20 managing module 14b stores the XML document of the 
order slip data as an XML document of management 
data and an XML document of content data to the 
database device 17. In the case, the data managing 
module 14b is a module having the function of the 

25 data managing module 2 shown in Fig. 3. The data 
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managing module 14b stores the order slip data to 
the database device 17 corresponding to the storing 
process shown in Fig. 4. 

When the format of transaction slip data such 
5 as estimate slip data and order slip data of an 
order issuer is different from that of an order 
acceptor, the data managing module 14b extracts 
relevant transaction slip data from the database 
device 17 and converts it corresponding to a 

10 predetermined converting process of the order 
issuer server device 14 and the order acceptor 
server device 16. In the converting process, for 
example, the fields of order information of 
transaction slip data are changed. Alternatively, 

15 the currency unit and various codes of the 
transaction slip data of an order issuer are 
changed to those of an order acceptor. In the case, 
the data managing module 14b is a module having the 
function of the data managing module 2 shown in Fig. 

20 3. The data managing module 14b extracts 

transaction slip data from the database device 17 
corresponding to the extracting process shown in 
Fig. 5. 

The data managing module 14b extracts order 
25 slip data to be transferred to the order acceptor 
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server device 16 through the network 15 from data 
of a plurality of order slips accepted by the order 
issuer server device 14 and stored in the database 
device 17 under the control of the transfer 
5 controlling module 14d and transfers the extracted 
order slip data corresponding to a predetermined 
communicating process of the order issuer server 
device 14 and the order acceptor server device 16. 
In that case, the data managing module 14b is a 
10 module having the function of the data managing 
module 2. The data managing module 14b extracts 
order slip data from the database device 17 
corresponding to the extracting process shown in 
Fig. 5. 

15 The transfer controlling module 16d of the 

order acceptor server device 16 receives 
transaction slip data from the order issuer server 
device 14. The data managing module 16b stores the 
transaction slip data as an XML document of 

20 management data and an XML document of content data 
to the database device 18. In that case, the data 
managing module 16b is a module having the function 
of the data managing module 2 shown in Fig. 3. The 
data managing module 16b stores the transaction 

25 slip data to the database device 18 corresponding 
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to the storing process shown in Fig. 4. 

Finally, the data managing module 16b of the 
order acceptor server device 16 extracts 
transaction slip data that matches the condition 
5 transmitted from the order acceptor browser 12 from 
the database device 18 and transmits the extracted 
transaction slip data to the order acceptor browser 
12. In that case, the data managing module 16b is a 
module having the function of the data managing 

10 module 2 shown in Fig. 3. The data managing module 
16b extracts the transaction slip data from the 
database device 18 corresponding to the extracting 
process shown in Fig. 5. 

Fig. 8 is a block diagram showing the 

15 structure of the system according to the embodiment 
of the present invention in the case that there are 
a plurality of order issuers, a plurality of order 
issuer servers, and a plurality of order acceptors. 

In other words, referring to Fig. 8, there a 

20 plurality of companies (companies A, B, and C) that 
have order issuer browsers each, a plurality of 
order accepter server devices (41 to 4n) connected 
to an order issuer server device 31 through a 
network, and a plurality of companies (companies P, 

25 Q, and R) that have order acceptor browsers each 
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connected to one of the order acceptor server 
devices. 

Referring to Fig. 8, a database device 
connected to the order issuer server device 31 
5 contains data of a plurality of transaction slips 
to be transferred to the order acceptor servers 41 
to 4n. Desired data of a transaction slip can be 
extracted from data of the plurality of transaction 
slips. The embodiment of the present invention is 

10 applied to such a system. Moreover, in the 
structure shown in Fig. 8, a database device 
connected to the order acceptor server device 41 
stores data of a plurality of transaction slips 
that is transmitted to order acceptor browsers 51 

15 to 5n. Data of desired transaction slip is 
extracted from data of the plurality of transaction 
slips. The embodiment of the present invention is 
applied to such a system. 

Referring to Fig. 8, only one order issuer 

20 server device 31 is shown. However, in reality, a 
plurality of order issuer server devices 31 may be 
connected to the plurality of order acceptor server 
devices 41 to 4n. A plurality of order acceptor 
browsers 51 to 5n of the order acceptor companies P 

25 to R may be connected to the plurality of order 
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acceptor server devices 41 to 4n, respectively. 

Figs. 9, 10, and 11 are schematic diagrams for 
explaining a transaction slip data format 
converting process. 
5 There may be a situation of which the formats 

of transaction slips such as an estimate slip and 
an order slip of an order issuer are different from 
those of an order acceptor. In such a situation, 
after transaction slip data is extracted, the data 

10 should be converted corresponding to the 
differences of the formats. In that case, the 
conversion controlling module 14c shown in Fig. 7 
executes the converting process for the extracted 
transaction slip data. On the other hand, when an 

15 order acceptor browser transmits transaction slip 
data to an order issuer browser, the conversion 
controlling module 16c executes the converting 
process for the transaction slip data. 

In the case that conversion tables 711 to 71n 

20 that contain transaction slip data format 
converting rules between transaction slip data of 
order issuers and transaction slip data of order 
acceptors and a conversion process controlling 
table 701 that correlates the conversion tables 711 

25 to 71n and combinations of an order issuer code 
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that identifies an order issuer in transaction slip 
data, an order acceptor code that identifiers an 
order acceptor therein, a transaction slip data 
type that identifies the type of transaction slip 
5 data such as an estimate slip or an order slip are 
used in the system shown in Fig. 8, when a system 
that defines management data document structure 
information shown in Fig. 10 is used, the content 
of the converting process can be determined and 

10 executed with keys of the order acceptor code, the 
order issuer code, and the transaction slip data 
type as shown in Fig. 11. In Fig. 10, the system 
uses a format described in DTD (Document Type 
Definitions) of the XML as the management data 

15 document structure information. In Fig. 10, the 
management data includes an order issuer code, an 
order acceptor code, and a transaction slip data 
type as management items. 

Fig. 11 is a flow chart for explaining the 

20 transaction slip data format converting process. 

Referring to Fig. 11, at step S30, a 
conversion table using keys as a combination of an 
order issuer code, an order acceptor code, and a 
transaction slip data type of the management data 

25 of transaction slip data to be processed is 
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determined. A loop from step S31 to step S33 is 
repeated for the number of slips to be converted. 
In other words, at step S32, corresponding to the 
conversion table, the transaction slip data is 
5 converted. At step S33, it is determined whether or 
not data of all the slips has been converted. When 
data of all the slips has been converted, the 
converting process is completed. 

In the structure of the system shown in Fig. 8, 

10 transaction slip data that is transmitted from the 
company A to the company P is transferred from the 
order issuer server device 31 to the order acceptor 
server device 41. When the extracted transaction 
slip data is transferred, the transfer controlling 

15 module 16d shown in Fig. 7 executes the 
transferring process for the extracted transaction 
slip data. On the other hand, when an order 
acceptor browser transmits transaction slip data to 
an order issuer browser, the transfer controlling 

20 module 16d executes the transferring process of the 
extracted transaction slip data. In the 

transferring process, the order acceptor server 
device 41 should change a transfer destination 
corresponding to an order acceptor coder that 

25 identifies an order acceptor in the transaction 
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slip data. 

Figs. 12 and 13 are schematic diagram for 
explaining a transaction slip data transferring 
process . 

5 Fig. 12 shows a route control table that 

defines an order acceptor code representing an 
order acceptor of transaction slip data and a 
transfer destination. When a system that defines 
the management data document structure information 

10 shown in Fig. 10 is used corresponding to the route 
control table, the content of the transferring 
process can be determined with a key of the order 
acceptor code of the management data shown in Fig. 
13. As a result, the transaction slip data 

15 transferring process can be executed. 

In other words, referring to Fig. 13, at step 
S35, with a key of a acceptor code of management 
data of transaction slip data to be processed, a 
transfer destination is determined corresponding to 

20 the route control table as shown in Fig. 12. In a 
loop from S36 to S38, the transferring process is 
repeated for the number of transaction slips. In 
other words, at step S37, transaction slip data is 
transferred. At step S38, it is determined whether 

25 or not all transaction slip data has been 
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transferred. When all the transaction slip has been 
transferred, the process is completed. 

Fig. 14 is a block diagram showing the 
structure of the system in the case that each 
5 section of the company R in the system shown in Fig. 
8 has an order acceptor browser and each section 
settles transaction slip data. Fig. 15 is a 
schematic diagram for explaining the process 
performed in the system shown in Fig. 14. 

10 When each section of a company settles 

transaction slip data, each section should search 
transaction slip data with a key of a code that 
identifies each section. In the structure shown in 
Fig. 14, transaction slip data for sections X, Y, 

15 and Z should be extracted. Thus, in the system 
shown in Fig. 14, a front end server device 1201 
that has the same function as an order acceptor 
server or an order issuer server is connected to 
the order acceptor server device 41 and order 

20 acceptor browsers of sections X, Y, and Z. 

Management data document structure information 
containing a section code shown in Fig. 15 is 
defined as management data document structure 
information of the front end server device 1201. In 

25 Fig. 15, as the management data, besides an order 
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issuer code, an order acceptor code, and a slip 
data type, an order acceptor company section code 
is registered. 

In the transaction slip data storing process 
5 of the front end server device 1201, since 
management data containing the section code is 
stored, transaction slip data can be searched with 
a section code as a search condition. 

When the XML is used, the definition of 

10 information of management data can be easily 
changed. Thus, when a company section code is 
required as management data, the company section 
code is extracted from transaction slip data as 
document data described in the XML corresponding to 

15 a tag of the XML and can be easily stored as 
management data. Thus, the supervisor of the system 
can dynamically change the content of management 
data. As a result, the supervisor can manage 
transaction slip data corresponding to a request of 

20 the user of the system according to the embodiment 
of the present invention. 

Fig. 16 is a block diagram showing an example 
of a hardware environment necessary for 
accomplishing the function of an order issuer 

25 server device or an order acceptor server device 
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with a program. 

A CPU 1502 is connected to a ROM 1503, a RAM 
1504, a communication interface 1505, a recording 
device 1508, a record medium reading device 1509, 
5 and an inputting/outputting device 1511. Management 
data, transaction slip data, conversion table, 
transfer destination table, and so forth are stored 
to the recording device 1508 such as a hard disk or 
a portable record medium 1510 such as a CD-ROM, a 

10 DVD, or a floppy disk. Data recorded on the 
portable record medium 1510 is read by the CPU 1502 
through the record medium reading device 1509. 

When the CPU 1502 performs an storing process, 
an extracting process, or a transferring process, a 

15 program that accomplishes such a process is read 
from the recording device 1508 or the portable 
record medium 1510 and stored to the RAM 1504. As a 
result, the CPU 1502 can execute the program. 
Alternatively, the program may be stored in a ROM 

20 1503 so that the CPU 1502 can directly execute the 
program. 

In addition, the ROM 1503 stores a basic 
program such as BIOS. When the system gets started, 
the basic program is executed so that the user can 
25 input a command from the inputting/outputting 
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device 1511 and a processed result is presented to 
the user. The inputting/outputting device 1511 is 
composed of a display, a mouse, a keyboard, and so 
forth. 

5 The communication interface 1505 accesses an 

information provider 1507 through a network 1506. 
The communication interface 1505 allows programs 
necessary for the CPU 1502 for the storing process, 
the extracting process, and the transferring 

10 process to be downloaded so that the CPU 1502 can 
execute the programs. When the network 1506 is an 
LAN or the like, the programs can be executed in 
the network environment. Alternatively, the 

database that contains management data and content 

15 data may be a database of an information provider 
connected to the network 1506. In that case, when 
it is necessary to process content data and 
management data, the CPU 1502 causes the 
communication interface 1505 to access the database 

20 of an information provider 1507 through the network 
150 6 so as to download and process required data. 

According to the present invention, a document 
structure of data elements to be searched is 
extracted from a document structure of transaction 

25 slip data. Management data and content data are 
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stored as different documents. The management data 
and the content data are linked with a document 
identifier. Since only management data is searched, 
the searching process can be effectively performed. 
5 In addition, since the structure of management data 
can be dynamically changed corresponding to the 
content of the electronic data exchanging process, 
a document managing function corresponding to the 
structure of the system can be provided. 

10 Although the present invention has been shown 

and described with respect to a best mode 
embodiment thereof, it should be understood by 
those skilled in the art that the foregoing and 
various other changes, omissions, and additions in 

15 the form and detail thereof may be made therein 
without departing from the spirit and scope of the 
present invention. 



